power: domain: Add Apple PMP reporting driver - #32

After discussion with the devicetree maintainers we agreed to not extend
lists with the generic compatible "apple,pinctrl" anymore [1]. Use
"apple,t8103-pinctrl" as fallback compatible as it is the SoC driver and
bindings were originally written for.
The t602x (M2 Pro/Max/Ultra) devicetrees submitted in [2] use this
compatible as fallback instead of "apple,t8103-pinctrl".

Link: https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe81bf@kernel.org/ [1]
Link: https://lore.kernel.org/asahi/20250828-dt-apple-t6020-v1-0-507ba4c4b98e@jannau.net/ [2]
Signed-off-by: Janne Grunau <j@jannau.net>

After discussion with the devicetree maintainers we agreed to not extend
lists with the generic compatible "apple,pmgr-pwrstate" anymore [1]. Use
"apple,t8103-pmgr-pwrstate" as base compatible as it is the SoC driver
and bindings were originally written for.
The t602x (M2 Pro/Max/Ultra) devicetrees submitted in [2] use this
compatible as fallback instead of "apple,pmgr-pwrstate".

Link: https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe81bf@kernel.org/ [1]
Link: https://lore.kernel.org/asahi/20250828-dt-apple-t6020-v1-0-507ba4c4b98e@jannau.net/ [2]
Signed-off-by: Janne Grunau <j@jannau.net>

After discussion with the devicetree maintainers we agreed to not extend
lists with the generic compatible "apple,spi" anymore [1]. Use
"apple,t8103-spi" as base compatible as it is the SoC driver and
bindings were originally written for.
The t602x (M2 Pro/Max/Ultra) devicetrees submitted in [2] use this
compatible as fallback instead of "apple,spi".

Link: https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe81bf@kernel.org/ [1]
Link: https://lore.kernel.org/asahi/20250828-dt-apple-t6020-v1-0-507ba4c4b98e@jannau.net/ [2]
Signed-off-by: Janne Grunau <j@jannau.net>

After discussion with the devicetree maintainers we agreed to not extend
lists with the generic compatible "apple,wdt" anymore [1]. Use
"apple,t8103-wdt" as base compatible as it is the SoC driver and
bindings were originally written for.
The t602x (M2 Pro/Max/Ultra) devicetrees submitted in [2] use this
compatible as fallback instead of "apple,wdt".

Link: https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe81bf@kernel.org/ [1]
Link: https://lore.kernel.org/asahi/20250828-dt-apple-t6020-v1-0-507ba4c4b98e@jannau.net/ [2]
Signed-off-by: Janne Grunau <j@jannau.net>

These SoCs are supported since 2022/2023 but were never added to the
documentation. The devices very similar to the equivalent M1 devices.
The biggest difference is that the M2 and M2 Pro/Max based laptops no
longer use SPI for the keyboard.

Signed-off-by: Janne Grunau <j@jannau.net>

Remove outdated apple,pinctrl.yaml. The dts/upstream contains the
current version of this binding.

Signed-off-by: Janne Grunau <j@jannau.net>

The device tree on Apple silicon devices is passed from a previous
bootloader stage. The bootloader fills in dynamic information so
u-boot can not use its own device tree.
As documented in doc/board/apple/m1.rst it is possible to build boot
bundles (bootloader + device tree + gzipped u-boot binary). These are
useful for testing.
Instead of using u-boot's own device trees for M1 (t8103) devices use
upstream device trees from dts/upstream/src/arm64/apple. The u-boot
device trees have not seen updates since 2022. The upstream linux device
trees have feature parity for the M1 devices. In addition linux has
device trees for M1 Pro/Max/Ultra, M2 and M2 Pro/Max/Ultra devices.
Keep t8103-j274 as default device tree to avoid further updates.

Signed-off-by: Janne Grunau <j@jannau.net>

The files weren't added to MAINTAINERS but clearly belong to Apple
silicon (M1) support.

Signed-off-by: Janne Grunau <j@jannau.net>

The main use case for u-boot on Apple silicon based devices is to
provide an EFI based bootloader for operating systems. This uses a
generic u-boot image with DTBs passed from an earlier boot loader
(m1n1). Use the generic board name "mac" for this purpose.

Signed-off-by: Janne Grunau <j@jannau.net>

The MTP HID driver will reuse this code, so split it off into another
file.

Signed-off-by: Hector Martin <marcan@marcan.st>

Apple M2 devices have an MTP coprocessor in charge of keyboard/trackpad
handling, communicating over a DockChannel interface. Add a simple
driver for this.

The keyboard does not require any initialization messages, but we have a
problem: we cannot reset the MTP so Linux can start it fresh, and it
delivers a number of informative packets on startup. To work around
this, we buffer those messages and re-inject them into the FIFO (which
is big enough to hold all of them) on shutdown, so Linux finds them when
it initializes its driver. The actual MTP coprocessor is quiesced, which
does work properly.

Signed-off-by: Hector Martin <marcan@marcan.st>

Signed-off-by: Hector Martin <marcan@marcan.st>

Find the appropriate EFI system partition on the internal NVMe
storage and set the U-Boot environment variables such that
the file system firmware loader can load firmware from it.

Signed-off-by: Mark Kettenis <kettenis@openbsd.org>

Add a variant of readl_poll_sleep_timeout that reads a single
byte to match the readb_poll_timeout API that Linux has.

Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

The ASMedia XHCI controller found on some of the Apple Silicon
machines needs firmware to operate.  Use the file system
firmware loader interface to read the firmware and load it
onto the controller.  This allows keyboards connected to the
type-A ports on these machines to function in U-Boot.

Signed-off-by: Mark Kettenis <kettenis@openbsd.org>

Now that we have a way to find the appropriate EFI system
partition on the internal NVMe storage, store the U-Boot
environment there.

Signed-off-by: Mark Kettenis <kettenis@openbsd.org>

Now that we have a way to find the appropriate EFI system
partition on the internal NVMe storage, nail it down as the
preferred EFI system partition such that we can use it to
store EFI variables.  This allows multiple OS installations to
exist on Apple Silicon machines without interfering with eachother.

Signed-off-by: Mark Kettenis <kettenis@openbsd.org>

When booting from a block io device, prefer the EFI system
partition over other partitions.

Signed-off-by: Mark Kettenis <kettenis@openbsd.org>

A bunch of miscellaneous debug messages to aid in working out USB
issues.

Signed-off-by: Hector Martin <marcan@marcan.st>

I have no idea what usb_stor_BBB_clear_endpt_stall was intended to do,
but it obviously can't work. When an endpoint stalls, the USB controller
stops it and needs to be told to restart it, you can't just send a
control message.

Signed-off-by: Hector Martin <marcan@marcan.st>

The old USB code was interrupt-driven and just polled at the top level.
This has been obsolete since interrupts were removed, which means the
timeout support has been completely broken.

Rip out the top-level polling and just pass through the timeout
parameter to host controller drivers. Right now this is ignored in the
individual drivers.

Signed-off-by: Hector Martin <marcan@marcan.st>

Now that the USB core passes through timeout info to the host
controller, actually hook it up.

Signed-off-by: Hector Martin <marcan@marcan.st>

0x9e isn't Read Capacity, it's a service action and the read capacity
command is a subcommand.

READ16 is not 0x48, it's 0x88. 0x48 is SANITIZE and that sounds like we
might have been destroying data instead of reading data. No bueno.

Signed-off-by: Hector Martin <marcan@marcan.st>

Some USB devices (like hard disks) can take a long time to initially
respond to read/write requests. Explicitly specify a much longer timeout
than normal.

Signed-off-by: Hector Martin <marcan@marcan.st>

This makes things work properly on devices with >= 2 TiB
capacity. If u-boot is built without CONFIG_SYS_64BIT_LBA,
the capacity will be clamped at 2^32 - 1 sectors.

Signed-off-by: Hector Martin <marcan@marcan.st>

We currently do not really handle altsettings properly, and no driver
uses them. Ignore the respective endpoint descriptors for secondary
altsettings, to avoid creating duplicate endpoint records in the
interface.

This will have to be revisited if/when we have a driver that needs
altsettings to work properly.

Signed-off-by: Hector Martin <marcan@marcan.st>

Signed-off-by: Janne Grunau <j@jannau.net>

Request the 16x32 font for display resolutions strictly larger than
FullHD.

Signed-off-by: Janne Grunau <j@jannau.net>

It is empty and automatic boot does not work.

This is a defensive commit against the fedora package which caries a
patch to default CONFIG_AUTOBOOT_MENU_SHOW to y.

Signed-off-by: Janne Grunau <j@jannau.net>

On Apple silicon machines u-boot's primary use is providing an UEFI boot
environment. It's not expected that AUTOBOOT is interrupted but it's
still desired to provide a clue that it is possible. Thios allows
booting from USB storage devices.

Signed-off-by: Janne Grunau <j@jannau.net>

Apple's M3 SoC is similar to M1 and M2 but uses a different memory map.
The main difference is that RAM starts at 0x100_0000_0000 like on t600x
and t602x (M1 and M2 Pro/Max/Ultra). Otherwise IO blocks have been
rearranged.
U-boot's existing drivers are compatible with the hardware and M3 device
trees will carry "apple,t8103-*" compatible strings. Only
apple-atcphy-reset might need a new compatible due to USB4 / DisplayPort
changes the Linux driver has to deal with.

Signed-off-by: Janne Grunau <j@jannau.net>

Signed-off-by: Janne Grunau <j@jannau.net>

Signed-off-by: Asahi Lina <lina@asahilina.net>

This reverts commit 595eafa.

Apple's M3 SoC is similar to M1 and M2 but uses a different memory map.
The main difference is that RAM starts at 0x100_0000_0000 like on t600x
and t602x (M1 and M2 Pro/Max/Ultra). Otherwise IO blocks have been
rearranged.
U-boot's existing drivers are compatible with the hardware and M3 device
trees will carry "apple,t8103-*" compatible strings. Only
apple-atcphy-reset might need a new compatible due to USB4 / DisplayPort
changes the Linux driver has to deal with.

Signed-off-by: Janne Grunau <j@jannau.net>

Apple's M3 Pro (t6030) and Max (t6031 and t6034) SoCs are similar to
their M1 and M2 predecessors. The MMIO blocks have been extended but
M3 Pro and M3 Max still share the same overall layout although they
aren't as similar as M1/M2 Pro and Max.
U-boot's existing drivers are compatible with the hardware and M3 Pro
and Max device trees will carry "apple,t8103-*" as fallback compatible
strings. Only apple-atcphy-reset might need a new compatible due to USB4
and DisplayPort changes the Linux driver has to deal with.

Signed-off-by: Janne Grunau <j@jannau.net>

Apple's M3 Ultra (t6032) SoC consists like its M1 and M2 predecessors of
two M3 Max dies with an "UltraFusion" interconnect. Since it is only
used in the Mac Studio the mem map does not need to duplicate all
entries. Two of the USB4 / Thunderbolt complexes on the second die are
unused. Only PCIe host controller on the first die is used directly. The
PCIe IO on the second die is used internally to connect the NVMe
controller with the NAND flash.
U-boot's existing drivers are compatible with the hardware and the M3
Ultra device tree will carry "apple,t8103-*" as fallback compatible
strings. Only apple-atcphy-reset might need a new compatible due to USB4
and DisplayPort changes the Linux driver has to deal with.

Signed-off-by: Janne Grunau <j@jannau.net>

The current code timeouts while trying to enable the "apcie_sys_st" NVMe
power states on Apple M3 Pro/Max SoCs. Ignoring these power states which
are marked as auto enable avoids the timeout with a working NVMe.
The Linux driver clears the auto enable bit but preserving the initial
boot state from Apple's iboot/mboot in u-boot seems preferable.

Signed-off-by: Janne Grunau <j@jannau.net>

The Power Management Processor (PMP) is a coprocessor found on certain
Apple SoCs.

This is a dummy driver which allows for devices bound to a PMGR domain
through a PMP reporting domain to be powered on.
Powering on the PMP itself is not necessary during boot.

Tested on M3 Max (T6034) with the nvme device tree node using one of
the PMP reporting power domains.

Signed-off-by: Yureka <yureka@cyberchaos.dev>